home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000064_owner-urn-ietf _Thu Mar 27 15:19:07 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  7KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id PAA28470
  3.     for urn-ietf-out; Thu, 27 Mar 1997 15:19:07 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id PAA28457
  6.     for <urn-ietf@services.bunyip.com>; Thu, 27 Mar 1997 15:18:59 -0500 (EST)
  7. Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA09674  (mail destined for urn-ietf@services.bunyip.com); Thu, 27 Mar 97 15:18:52 -0500
  9. Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id OAA21967; Thu, 27 Mar 1997 14:18:45 -0600 (CST)
  10. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  11. Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id OAA21868; Thu, 27 Mar 1997 14:18:40 -0600 (CST)
  12. Date: Thu, 27 Mar 1997 14:18:40 -0600 (CST)
  13. Message-Id: <199703272018.OAA21868@void.ncsa.uiuc.edu>
  14. To: Patrik Faltstrom <paf@swip.net>
  15. Cc: urn-ietf@bunyip.com
  16. Subject: [URN] draft-ietf-urn-nid-req-01.txt
  17. In-Reply-To: <Pine.SUN.3.95.970326220023.530E-100000@nix.swip.net>
  18. References: <Pine.SUN.3.95.970326220023.530E-100000@nix.swip.net>
  19. Sender: owner-urn-ietf@Bunyip.Com
  20. Precedence: bulk
  21. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  22. Errors-To: owner-urn-ietf@Bunyip.Com
  23.  
  24. Several points in the document are actually about resolution, but as
  25. Leslie says:
  26.  
  27. Leslie Daigle <leslie@Bunyip.Com> wrote:
  28. >     2.  This is about what it takes to define a new URN  namespace,
  29. >         not what it takes to set up and run a resolver for an
  30. >         existing one
  31.  
  32. Regardless of whether it is a new newspace or an existing one, there
  33. is a separation between the definition of the name space and the
  34. resolution service(s) for that space.
  35.  
  36. Patrik Faltstrom writes:
  37.  >  Global Scope and Uniqueness.
  38.  > 
  39.  >   - The NID must be registered with IANA to ensure uniqueness and
  40.  >     demonstrating that it meets the requirements listed in this
  41.  >     document.
  42.  
  43. Who registers a name space if anyone can, in fact, resolve identifiers
  44. in the name space?  Does someone "own" the name space?  Some name
  45. spaces might be owned by a corporation or individual.  Others might be
  46. owned collectively.  Others might be public domain, if that is
  47. possible.  No matter who owns the name space, who is *allowed* to
  48. resolve identifiers in the name space?  This is part of the definition
  49. of the name space.
  50.  
  51.  >  Persistence
  52.  
  53. A fundamental mixup regarding the nature of names and resolution
  54. becomes evident in the following.
  55.  
  56.  >   - The NID service providers must show that they intend to
  57.  >     support the service for an indefinite period of time.
  58.  
  59. What is a NID service provider in this case?  Someone who provides the
  60. service of registering new names or someone who resolves names at the
  61. request of clients?  Just to be clear, I'll call them, respectively,
  62. NID registration service and NID resolution service.  Why does a NID
  63. registration service need to continue to exist indefinitely?  If it
  64. stops the registration service, the only thing that happens is that
  65. new names cannot be registered.
  66.  
  67. Another notion of persistence for identifiers is that they may
  68. continue to be resolved indefinitely, if they are resolvable at all.
  69. In other words, a client can always find *some* resolution service that
  70. will resolve a particular identifier.  Thus it is the service of
  71. *finding* a resolution service that must be persistent, not the
  72. resolution services themselves.  So why does a NID resolution service
  73. need to continue to exist indefinitely?
  74.  
  75. The service of *finding* a resolution service needs to be at least
  76. as persistent as the resolution services, otherwise what is the
  77. point of making use of the finding service?  
  78.  
  79.  
  80.  >   - Support facilities must be described and how the service
  81.  >     intends to operate, including "disaster recovery"-like
  82.  >     operations.
  83.  
  84. Disaster recovery for the NID registration service?  Why bother?
  85.  
  86. Disaster recovery for the NID resolution service is useful, but if
  87. there are replia services, as there should be, what is the big deal?
  88.  
  89.  >   - Demonstrated experience in managing an established namespace
  90.  >     system is essential.    
  91.  
  92. What is so hard about managing the NID registration process?
  93.  
  94. Resolution is another matter.  Doing it scalable takes not just
  95. experience on a small scale but the right algorithms that are
  96. appropriate on a large (and long) scale.  One can show by arguments
  97. that a system is scalable or not scalable.  One can also do
  98. experiments, but there is nothing like the real thing for experience.
  99. So how can we tell whether a system will actually work?  Who should
  100. stand in judgement?
  101.  
  102. But why do we need to bother worrying about this.  The point of having
  103. a service for *finding* resolution services is to allow multiple
  104. resolution services so that some resolution services can fail and others
  105. will fill in.
  106.  
  107. How can we ever impose on a service to promise to exist indefintely
  108. anyway?  Such a promise would certainly be a lie.
  109.  
  110.  >   - One URN should never be reused for a different resource (where
  111.  >     "different" is defined as in previous paragraph by the namespace).
  112.  
  113. This is persistent registration.  Not at all difficult.
  114.  
  115.  >     The URN should be persistent for all times, even though the
  116.  >     resource goes away.
  117.  
  118. This is ambiguous, given the above.  Is this just a restatement of the
  119. persistent uniqueness requirement, or do you mean persistent
  120. resolution?
  121.  
  122.  >  Independence
  123.  > 
  124.  >   - The NID service providers must also show any relationship
  125.  >     (both technical and administrative) that may impede on the
  126.  >     provision of the URN service.
  127.  >   - However, multi-party participation in the NID service is
  128.  >     an advantage.
  129.  
  130. This sounds like you are assuming the NID name space is owned by
  131. some party that may consist of multiple cooperating parties.
  132.  
  133.  >  Resolution
  134.  
  135. Ah, now this is definitely about resolution.
  136.  
  137.  >   - The NID service providers must produce an RFC
  138.  >     describing the technical characteristics of the URN
  139.  >     resolution service, including security considerations.
  140.  
  141. On the one hand, I would agree that the resolution issues should be
  142. considered separately from the name space definition issues.  But
  143. how do you really separate them?  In practice, the same agency is
  144. likely to be involed in both definition and resolution.  More
  145. importantly, the structure of the name space, assuming it is
  146. structured, will have a lot to do with how identifiers are resolved.
  147.  
  148.  >   - The NID service providers may elect not to have the
  149.  >     resolution service publically available.
  150.  
  151. Ah, a public *finding* service for private resolution services.
  152. Hmm, how will this sit with the anarchists among us?
  153.  
  154. Leslie again:
  155. >     3.  If we are unlucky, this is about as difficult and subjective as 
  156. >         iTLDs.  "Enforcement" will require judgement.
  157.  
  158. No question about it.  This is even more difficult and subjective than
  159. TLDs.  It is hard enough just to deal with ownership issues.
  160.  
  161. There is another way to deal with all this much more simply: in a
  162. nutshell, delegate hierarchically and let each authority deal with
  163. meeting the requirements.  Anything more invasive is asking for
  164. trouble.
  165.  
  166. --
  167. Daniel LaLiberte (liberte@ncsa.uiuc.edu)
  168. National Center for Supercomputing Applications
  169. http://union.ncsa.uiuc.edu/~liberte/